home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 3 / Cream of the Crop 3.iso / utility / fsco3712.zip / SPECS.DOC < prev   
Text File  |  1993-12-13  |  4KB  |  74 lines
  1.             *FSCODE FILE FORMAT SPECIFICATIONS*
  2.                 By Flavio Stanchina
  3.  
  4. FScoded files begin with the line
  5.  
  6.     !start <file name>
  7.  
  8. The <file name> is everything that follows the space after `!start' until the
  9. end of line, spaces included; it is recommended to replace spaces with
  10. underlines on machines incapable of using spaces in file names.
  11.  
  12. Then follows the encoded data; each group of 5 characters represents a
  13. longword of the original data converted in base 85, using the ASCII
  14. characters from 42 (;-) to 126 (from `*' to `~') as digits, most significant
  15. digit first, and padded with "zeros" (remember that our "zero" is really
  16. `*').  Encoded data can be arbitrarily interspersed with blanks (spaces, line
  17. feeds, etc), that are to be skipped when reading in the data for decoding.
  18.  
  19. You might have noticed that not all files are longword-aligned in their
  20. lenght:  for this reason, the last group of five characters can contain the
  21. character `#' (ASCII 35) in it's one to three most significant digits, which
  22. means that one to three of the most significant bytes in the last longword
  23. are to be considered empty and are not to be written to the output file when
  24. decoding.  For example, a file of length 2 would look like this:
  25.  
  26.     !start 42
  27.     ##+r;
  28.     !end 2 A8D1BE1F
  29.  
  30. This means that you must decode this longword of data as if it was only 3
  31. characters long (this is equivalent to taking the #'s as *'s, i.e zeros) and
  32. write out only the two least significant bytes.  Probably you can manage to
  33. understand all of this by looking at what happens in the Decode() function
  34. when a `#' is found.
  35.  
  36. Please note that the current implementation does neither check that the file
  37. correctly terminates after a partially filled longword, nor allow a partially
  38. filled longword to appear in the middle of the file (which would be somewhat
  39. easier to do, but would slow down a bit the decoding).  If it finds a `#' in
  40. the middle of the file, it will simply mess up the decoding process from
  41. there on.  However, the encoding routine does it right, so why should the
  42. decoding fail?  :-)
  43.  
  44. Decoding stops when the ending line is found.  It has the form
  45.  
  46.     !end <size> <CRC>
  47.  
  48. with <size> in decimal and <CRC> in hexadecimal representation.  <size> is
  49. the size in bytes of the original file.  <CRC> is a 32-bit CRC calculated
  50. using the polynomial 0x04C11DB7 (AUTODIN II, Ethernet, & FDDI); the algorithm
  51. has been taken from the comp.compression FAQ list of october 1992, but has
  52. been changed to NOT complement the resulting CRC for simpler implementation.
  53. See the source code for the exact algorithm.
  54.  
  55. Control lines (`!start' and `!end') must start on the first column; the `!'
  56. character has been chosen as the introducer of the control lines because it
  57. is not used in the encoded data, thus provides a reliable way to distinguish
  58. the two kinds of input.
  59.  
  60. // The `start' and `end' keywords can be lowercase, uppercase, or a mixture
  61. // of the two, but it is recommended to write them out as lowercase for
  62. // consistency.
  63.  
  64. Some notes on the encoding method.  85^5 is slightly greater than 2^32; this
  65. is the best compromise between simplicity and speed on one side, and
  66. efficiency on the other, if we want to encode all possible 256 byte values to
  67. the limited set of 95 ASCII characters allowed over the various nets.
  68. Encoding more bits at a time would require quite complex algotythms, because
  69. most computers and most programming languages (C, in particular) do not have
  70. arithmetic instructions that can handle numbers wider than 32 bits; on the
  71. other side, to increase efficiency over this method you should encode as much
  72. as 32 bytes at a time into 39 characters, gaining only one character over 40.
  73. Definitely too much trouble.
  74.